 The techniques we used played a big role in how the project unfolded. This section will go through
 why we chose to use the techniques we chose and how we experienced them in practice.
 
 \subsection{Eclicitation}
 During the project we have used several of the techniques found in the course material.
 We started with a technique call \emph{Documentation studies} where we read through the project PM
 delivered by our customer group A. The reasoning behind this was to get a better understanding of
 the product the customer wanted. It felt like a good idea to start here instead of for example starting
 with a brainstorming session most of the other techniques would yield a lot of bad results if we didn't
 know where to focus our efforts.
 
 In retrospect it was a good way to start the elicitation since it resulted in us finding most of the 
 big feature requirements which were later used during the rest of our elicitation as a staging point 
 from where we could further broaden our view of the product.
 
 After studying the PM we had our first \emph{Brainstorming} session. The choice of brainstorming were to get
 many requirements to work with. As we thought, we elicitated quite a bit of requirements this way, mainly
 functional but also a few quality requirements that we could later evaluate to see if they were good enough
 to keep. 
 
 We were pleased with this order of technique usage seeing as it panned out as we thought. 
 It was a big help to have something other then a vague idea in mind when brainstorming so the
 documentation studies really helped out in improving the amount of elicitation made. Brainstorming
 is a powerful technique which will produce a large quantity of requirements if used correctly. 
 
 The first brainstorming session was very closely followed by a \emph{Companies analysis} where we studied
 other similar products to see what they had done and more importantly what they had not done. The most
 substantial result of this was to overhaul the project and change the scope. By doing so we had to discard
 a lot of the requirements we had already elicitated. If we could do it again we would do this step before the
 first brainstorming session in order to further set the scope and boundaries of the project to avoid
 elicitating requirements which are not useful.
 
 Following the Companies analysis we chose to use a technique called \emph{Negotiation} so that we could 
 discuss with the product owners how to proceed after our discoveries from the analysis. Negotiations as an
 elicitation technique gave more detailed requirements such as design and quality requirements mainly due to
 the fact that we had already gotten a good grasp of what the competition had done. The technique also
 gave us further insight to how our product owners wanted the product to work while helping us to let them
 know of some limitations for the project. 
 
 \emph{Group interviews} with the product owners were held and served as a technique to see which requirements we had missed. 
 The best way to know if there is something missing is to ask the product owners even if you don't catch everything with
 an interview at least some requirements were found using the interviews. The interviews were useful in a very similar
 way to the negotiation serving mainly to deepen our understanding of the product but also showing
 what we had missed.
 
 Another similar technique we used was \emph{Focus groups} which we chose since it's very apt in
 dealing with detail requirements such as "Should this icon be limited in size?" et cetera. Combining
 prioritization, validation and elicitation in one technique worked really well for us since while we 
 prioritized and validated it was very easy to see which areas we didn't need to focus more on and 
 what areas we had missed requirements in.
  
 After RDv1 was turned in we noticed that we lacked some quality requirements so we chose \emph{Task demonstration}
 and \emph{Stakeholder analysis} as our last elicitation methods. Task demonstration would help by imagining
 limitations that were needed when we went through the task descriptions. Stakeholder analysis were to help us 
 get a clear view of what limitations and quality the different stakeholders wanted from the system.
 
 Overall the outcome of our chosen techniques provided us with what we think is a requirements document
 complete enough to make a real implementation of the product using our project. If we could do it again
 with our current knowledge of how they work the biggest changed would be to do the Companies study
 right after the Documentation studies. This would've helped us to avoid unnecessary work and also provided
 a better first brainstorming session.
 

\subsection{Specification}
 When the elicitation had started to result in requirements we needed to specify them. So we started to
 make a \emph{Context diagram} so that we could see which actors were to interact with the system and
 from that we could specify how they were going to interact with it. However we noticed rather early that
 a smartphone application does not have many interactions from other actors than the user which meant that
 there were not many requirements specified this way.
 
 We moved on from the Context diagram to making \emph{Virtual windows} since we wanted to get a grasp on which 
 data should be shown to the user. Again we noticed that there was not a lot of information that should be
 shown to the user according to the smartphone application guidelines. However the Virtual windows served 
 a greater purpose by helping us when creating the \emph{Screenshots}. These Screenshots were of great
 help when we specified quality requirements regarding size of objects shown, how many objects that
 should be shown at a time et cetera. 
 
 Although the Virtual windows didn't specify all that many requirements since not much data is shown to
 the user there is data stored out of view. We needed to specify these requirements as well and chose to
 use a \emph{Data model} to accomplish this. This resulted in some overlap with the Virtual windows but
 the Data model fulfilled it's purpose by specifying the rest of the data requirements.
 
 Our first technique to specify various features was \emph{Task description} which was chosen since they
 give a good understanding of which basic actions can be done with the system. This technique was very 
 useful since it not only let us specify features and functionality but also by going through them we 
 could specify some quality requirements as well. Task descriptions does not however cover all of the
 features provided by our system so to further specify the features we chose the \emph{Feature requirements}
 technique. This choice was made since it's a very straight forward technique that is also useful as 
 a checklist to see if all features are added. 

 The final technique we used was QUPER which we chose since it's a very good technique to get quality
 requirements to be of the right degree. Although due to time restraints we couldn't use it on more 
 than a few requirements we feel that it is very useful and definitely worth the extra time spent.
 
 In retrospect using Virtual windows for a smartphone application might be a bit unnecessary since you
 go straight to the screenshots. Besides this we felt that the techniques we chose served their purpose
 and helped a lot during the specification periods. 

\subsection{Prioritization}
 For priorization we only used two techniques where the first techniques was a \emph{Numerical grading}.
 The choice here was easy, we wanted something simple to use during our group interview mainly to get 
 further understanding about which areas of the product that the product owners were most interested in
 focusing the requirements. It served it's purpose well but it shouldn't be used as a basis for in depth
 prioritization.
 
 For a proper in depth prioritization we chose to use \emph{Focal point}. During our lab with Focal point
 we saw the potential of the application to optimize the prioritization process. Preparing for the prioritization
 was a bit time consuming but it payed of by giving both us and the product owner a much faster and 
 reliable relationship between the requirements.


\subsection{Validation}
 For validation we only used a \emph{Checklist} based technique. Simply going through all requirements with
 the product owners and having them say either "Yes we want that" or "No we don't want that" seemed to suffice
 with the amount of requirements we had elicitated. Had the project been bigger the validation on design level
 would probably have had to be done with the help of more advanced techniques.